OpenEdge Deployment:<br />Managing 4GL Applications CRC versus time stamp validation

The main advantage of using CRC validation is that you can run the same r-code against different databases as long as the databases have sufficiently similar schemas. This allows you to deploy code and database updates while avoiding either of the following effects:

Forcing the user to dump and reload their data into a new database that you supply with new r-code.

Forcing the user to compile new source code (possibly encrypted) that you supply with new data definitions to update their database schema.

Depending on the schema changes, the user still might have to dump and reload some data, but you can always supply r-code for their updated database.

Database changes that affect time stamps

You must recompile procedures that reference a database table in which you have made any of the following changes:

Deleted the table.

Changed the table name.

Changed the database language or authorization key.

Added or deleted a field in the table.

Changed the name or order of a field.

Added or deleted an index.

Modified an index by changing its name, uniqueness, field components, collation order, or the abbreviation option.

Although you do not have to recompile procedures when you make other schema changes, such changes do not apply to procedures that you do not recompile. For example, changes to the following features appear only when you recompile:

Field appearance — format, label, column label, and decimal.

Data entry — initial value, mandatory value, case sensitivity, validation expression, delete validation, and security.

User information — help messages, validation messages, and description.

Database changes that affect CRCs

You must recompile procedures using CRC-based deployment for the same schema changes that change a time stamp, except for index changes. (You can add, modify, and change indexes without affecting the CRC of the table so you do not need to recompile.) In addition to the schema changes listed in "Database changes that affect time stamps" section, you must recompile procedures that reference a database table in which you have made these changes to a field:

The data type or extent (array size).

The number of decimals.

The case sensitivity.

Table B–2 lists all the metaschema fields involved in database CRC calculation.

Time stamp-based deployment

Using time stamp validation, if you deploy r-code, you must compile the procedures against a schema-updated version of the user’s database and send both the r-code and the new database to the user. Otherwise, the r-code cannot run, and you must deploy source code for the user to compile along with new database definitions to update their schema.

CRC-based deployment

Using CRC validation, if you deploy r-code, you only have to compile the procedures against a database with the same basic structure as the end-user database. It does not matter when or where the database was created. If you make schema changes to an existing database, you can distribute the newly compiled r-code to end users, along with a data definition files to install the schema changes.

The flexibility of CRC-based deployment makes it easier to distribute a new version of an existing application.

Install a copy of the production database from the target site in your development environment.

Create an incremental data definition file that captures the difference between your development database and the production copy. For information about creating an incremental data definition file, see OpenEdge Data Management: Database Administration .

Apply the incremental data definition file to your copy of the production database.

Recompile all procedures affected by the schema changes against your copy of the production database.

Apply the incremental data definition file to the original production database (on site). The CRC for the original production database should now be identical to the production copy, but probably not identical to your development database.

Distribute the new r-code files (from Step 4) to the updated production site.

The steps for CRC-based deployment are essentially the same as those for time stamp-based deployment, but you gain these advantages:

You are not required to encrypt and give end users source code.

End users do not have to compile your source code.

You do not have to send a copy of a new database to end users.

End users do not have to dump and reload all their data into your new database.

Differences in r-code access authorization

One possible drawback of using CRC validation is that anyone having an OpenEdge development environment can create a counterfeit database (a database with the same structure as your database). The user can then write a program, compile it, and run it against your database. Using time stamp validation prevents this because the time stamps in the counterfeit code do not match those in your database.

However, you can also combine CRC validation with additional security to prevent unauthorized r-code access. You can either turn on run-time permission checking or use the PROUTIL utility’s DBAUTHKEY qualifier. For details on how to turn on run-time permission checking, see Chapter 3, " Maintaining Application Security."

The DBAUTHKEY option of the PROUTIL utility allows you to set an authorization key for your database. When you compile your source code, OpenEdge includes the value of this authorization key in your r-code. You can also use the RCODEKEY option of PROUTIL to insert the authorization key in existing r-code. Any r-code that does not include the correct authorization key cannot run against your database. For more information about using PROUTIL to create and set database authorization keys, see OpenEdge Data Management: Database Administration .

CRC and time stamp availability

During compilation, OpenEdge always inserts both database time stamps and CRCs in the r-code. If a database is not connected with the Time Stamp (-tstamp) parameter during procedure compilation, OpenEdge turns on a bit in the r-code. This bit tells the run-time interpreter to check the CRC if the time stamp check fails.